1. Field of the Invention
The present invention concerns computer systems in general, and a method for running diagnostic utilities in multi-threaded operating system environments in particular.
2. Background Information
Diagnostic utilities are used to determine whether a hardware device, such as an adapter card or motherboard PCI device, is functioning properly. Typically, when a diagnostic utility is launched, a predetermined set of diagnostic checks will be performed to ascertain the functionality of the device being checked. A result set will be returned to the diagnostic utility in response to the checks, and the diagnostic utility will provide result feedback to the user.
In general, diagnostic utilities may be provided by the operating system, the system manufacturer, or the component manufacturer. For example, in Microsoft Windows operating systems, such as Windows 2000, a user may run diagnostics on various system components by opening the control panel and navigating to either a built-in diagnostic check, such as those provided by the system manufacturer, or activating the system icon and then selecting the hardware tab from the system properties dialog. This will present a screen that enables the user see properties of various hardware devices by selecting the “device manager” button and then selecting the hardware device. Many of the devices will have build-in diagnostic checks that may be run from that devices properties dialog (e.g., via a “diagnostics” tab).
In addition to accessing diagnostics via the control panel, diagnostic programs may be launched via other user-interface means, such as the start menu or via an icon present in the taskbar tray. The use of taskbar trays has become increasing popular since the enable users to easily launch programs and utilities without having to navigate one or more menus.
Depending on the type of device being tested, various system resources may need to be available to complete the tests. Use of these resources may slow down a system or even make a system appear to be frozen. Even worse, if some diagnostic utilities are launched with insufficient available resources, the diagnostic utility may cause the operating system to crash, requiring the user to reboot the system.
Examples of problems encountered using a typical network adapter diagnostic utility are illustrated in FIGS. 1 and 2. FIG. 1 corresponds to a “frozen” system problem during which the system appears to be inaccessible while all or a portion of the diagnostic utility is running. A utility that enables operation of the network adapter (i.e., an operating system driver and other support modules/drivers) is loaded into memory in a block 10. During a typical user session, the user activates a diagnostic utility in a block 12. The network adapter diagnostics load and run on a selected network adapter in a block 14, including cleaning up memory in a block 16. Due to resource contention or conflicts, the operating system, such as Microsoft Windows, locks up for 10–20 seconds in a block 18. During this time, the user has no control over the system keyboard or mouse. The adapter diagnostics finally return control to the operating system in a block 20.
FIG. 2 illustrates a problem that causes the operating system to crash, as follows. As before, the adapter utility is loaded into memory in a block 22, and the user activates the diagnostic utility in a block 24. The network adapter diagnostics are then loaded in a block 26, and start to run on a selected network adapter in block 28. In this case, the resource conflict (e.g., lack of resources) causes Microsoft Windows to display a blue screen indicating a fatal condition has been generated, as indicated by a block 30. Under this condition, the user must reset the computer system in a block 32.